Alright, welcome back to Software Engineering.

Great to see that not everybody is attending the Bergh-Kirchwein.

There's actually some people here in the lecture hall and not everybody is just watching recordings.

So that's nice to see.

And yeah, today we want to continue our journey in software engineering.

And you see that the whole storyline of this lecture is that we want to enable good cooperation

and good design in software projects.

And you may remember you started with the general idea why we need software engineering.

One of the basic ideas why we started working on software engineering is because simply

many software projects failed and software projects are different from classical manufacturing

processes therefore you need specific guidelines for software projects.

And in particular communication, spotting communication errors, miscommunication is

key.

It's really a key thing that needs to be tackled in order to develop good software.

Right now quite frequently you do tasks in teams of small groups.

But the large software projects, they will have to run in really big groups.

And the larger the group gets, the more difficult the communication is.

And therefore we then have seen that there's classical approaches like the waterfall model

where you start with a specification and then implement.

And then we've seen an improved version or an expanded version is the V model where you

have corresponding checks that everything that you think of, plan and then guide is

connected to a check before you actually deliver your product.

So these were guiding principles.

We've then seen that in particular agile models are quite popular because they allow you to

adapt your plans rather frequently and you can react to miscommunication if you had a

misunderstanding of the desires of your potential customers.

So then you can adjust for that.

And then we started really digging into the actual software engineering and we started

with the very beginning, the requirements where we specify what will be the outcome

of our development process.

And now we are essentially following the storyline.

We first had an overview.

What do we need?

And we've seen at all points, at some point we need to specify something in agile.

We specify quite frequently and the plans can change very quickly.

But we have to find specifications and based on that we're starting implementing them.

And depending on which process model you're using, you're implementing and going back

and forth more frequently or not.

But it is still crucial that we really have steps from planning software then to designing

software structures up to the real implementation and then also check whether whatever we implemented

is what we wanted, which will then be the testing.

So this is the whole pipeline and depending how you work in your team, you will have a

different structure.

But for all of these processes, you will need certain ways of to communicate.

In requirements engineering, we have seen that in particular getting the specification

right is key.

And a lot of things have to be done in order to make people communicate.

And we looked into some techniques like interviews, where you can really talk in detail to questionnaires,

to brainstorming sessions and so on.

But it's really about figuring out what is needed.